Test systems are widely used to test semiconductor devices at multiple stages during their manufacture. A test system includes components, called resources, that can generate and measure signals that can establish and measure an operating state of a device under various conditions. A resource, for example, may be an arbitrary waveform generator that can be programmed to generate a waveform of a desired shape. Another type of resource may capture a sequence of samples of an analog signal. Yet another type of resources may generate or measure DC voltages or currents or digital signals. A test is executed by controlling the resources to generate and measure test signals at multiple test points of a device under test.
Before executing a test, the test system is configured for the particular type of semiconductor device being tested. The test, in conjunction with the configuration information needed to configure the test system to execute the test, may be regarded as a test plan. This configuration information may involve multiple levels of mapping to relate one or more resources in the tester to each of the test points on a device under test. For example, a test system may have access points, sometimes called “channels,” at which signals to or from resources may be accessed by components that connect the test system to a device under test.
A mapping may be specified between one or more resources and each of the “channels” of the test system where signals to or from those resources can be accessed. A test system may also include an interface that maps each channel to a location, sometimes called a “pin,” at which a connection to a specific test point on a device under test can be made. With these mappings, the test system can determine which resources to control to generate or measure a specific type of signal at a specific test point of a device under test.
A test system may include more resources than are required to test a single device under test. To speed average test time, and therefore reduce the cost of manufacturing semiconductor devices, the test system may be programmed to test multiple devices concurrently. Each device may be positioned at a user site during testing. To support testing of multiple devices, some test systems support tester-sites. Each tester-site may be connected to a user site such that each tester site may generate or measure the test signals for a device under test. When using multiple tester-sites, each tester-site may be configured with functionally equivalent resources such that the same types of signals may be generated or measured at each tester-site, thereby testing multiple devices coupled to the user sites concurrently.
In an embodiment in which tester sites are supported, user inputs may specify a test program and resource configuration that would be needed to test a representative device. Separately, the user may specify information about the user sites. An automated tool may aid the user determine how to configure the tester resources to have an instance of the test program running for each user site. Each instance of the test program may control an associated tester site. Accordingly, a further aspect of configuring a test system for testing multiple semiconductor devices may entail specifying which resources collectively form a tester-site. Using this information, the test system can then concurrently execute an instance of a test program for each of the user sites.
To support such concurrent test, the test system may support tester-site specific operations. The test system hardware, for example, may allow resources assigned to a tester site to be controlled together so that the resources of a tester-site can be started or stopped together. Additionally, the resources in each tester site may be operated independently of resources in other tester sites. With this independence, the test system may be controlled such that the resources associated with each user site operate in a way that is conditioned on measurements at that site. As a result, test execution in each user site may be controlled dynamically based on tests conducted on a device under test. For example, a test system may detect an erroneous operating condition associated with a device at one user site. The test system can flag that device as faulty while continuing to test devices at the other user sites. Those tests of other devices may continue even if the test system stops testing a faulty device connected to one of the user sites.
As semiconductor devices have gotten more complex, the complexity of testing has also increased. For example, semiconductor devices now may be designed with multiple “cores,” each core performing a function. As a specific example, a semiconductor device may have a processing core, which performs digital computations and control functions. A separate core may generate audio output and yet another core may control a radio or other network interface. A test program for such a semiconductor device may be developed as multiple test blocks. Each test block may control resources to generate and measure test signals for testing a core.
Some cores may be functionally independent such that the test blocks for those cores can be executed at the same time without one test block interfering with results of the others. Though, some test blocks need to be executed at different times, either because cores within a device cannot concurrently operate independently or because a test system lacks sufficient resources to test all instances of the cores concurrently.
A further aspect of configuring a test system may entail specifying a “flow.” The flow indicates the order in which test blocks are executed for testing a representative device. In a test system supporting multiple user sites, multiple instances of the flow may be executed, one for each user site.
When multiple test blocks can be executed concurrently, the flow may have multiple sub-flows, with each sub-flow being executed concurrently. When multiple user sites are used, each of which has a device with multiple cores, a test may entail at each user site a flow-instance, with each flow instance containing multiple sub-flows.